Umm well the first sector of the disk are you refering to the file FF9.img or are you refering to the entire disk? IE mode 1 Form 1 0:0:0 or LBA 0 on the disk?

If it's the file that's probably good (LOL).
The reason the file is in 0x800 byte chunks is that is the playstation sector size, which makes it easier to seek data in the program. Likely to be read in Mode 2 form 1 this might be the reason I've been having some trouble dealing with the data analysis (hmmm) because the header may shift it 8 bytes if it's a Mode 2 sector.  Windows does not deal with the larger sector size of Mode 2 form 2 at all (shrug).

In any case a quick look at the structure indicates that the directory information is fairly simple it just has a list of sector count and start values.

What is the difference to you between an array of files and a directory?  04 may indicate that there isn't anything more in directory entries.
Your 02 and 03 designations puzzle me. I'll have to look at what it means using the actual data.

I'll write a quickie bit of code to use this information to see if it works right. I can also detect TIM and model files already, and possibly find the field information files as well with this. PRIOR to this what I did was search through the image file and make references. However with exact pointers this will change things a lot in terms of knowing where data is and decoding it.

Cyb

AKAO is related to sound. It's the name of Square's sound guy and has the honor of even having a fieldscript command named after him.

Thank you, halkun. I thought that was the case so I decided to leave it for later as I'm used to looking into graphics and code, not sound for the Playstation. I'll read the document I found in the forums about the sound chip.

chaoscontrol: He's refering to the sound programmer, not the music guy (composer.)

Wow, I wasn't expecting a full fledged application, but that looks great. :) Look... I don't want trouble with the fans of the ff7 engine. ;)

So, we have different number of files in DIR01, but the other directories have the same number of files.

The flags for the files in DIR00 are the same I have, but there are some differences in the starting sectors, so there must be differences in the sizes. Those must be files where localization was needed, but we shouldn't have differences in most graphics, sound, etc.

Comparing the data for DIR00 I get:



Some of the files I have are bigger than yours. I think a sentence in Spanish has a little bit more characters than a sentence in English, but I couldn't find a reference to confirm this. And I don't see why an image, even translated, would have a different size.

Are you saying that F<00>000 has only a byte with value 0x15? Mine is a little bit strange: It has some 'JFIF' tags and a few "Photoshop" strings. JPEGs in the psx? I couldn't decompress them, but the headers are similar to a JPEG.

I have the same kind of information as you do in F<00>001. The strings are in English so they weren't meant for translation and as you say, they show some debugging information.


Most of the files in DIR00 start with an identifier, followed by a table of values 0x80wwyyzz. Can these be memory addresses from some sort of relocation table?


I think I'll take a closer look at the files in DIR00. There are some images not in TIM format in some of the files that may help classify them and to find some pointers.



----------------------

I looked into DIR00 for graphics and there is certainly a pattern. All the images I found are noticeable in greyscale, but most of them have a palette before the image and the greyscale value is the index. I'm still trying to find height and width attributes.

It should be easy to figure out the purpose of some of the files.


F<00>007:
25 low contrast images. Chocograph targets. (width=42)

F<00>010:
Symbols for the cards game. (width=128)
Rose of the Winds. (width=84)

F<00>011:
Paper-like key item background. (width=88)

F<00>013:
Portraits of 10 characters. (width=32)
Animation. Passing pages of a book. (Accessing memory card.) (frames=4; total_width=176)

F<00>014:
Portraits of 13 characters. (width=32)

F<00>015:
Portraits of 13 characters. (width=32)

F<00>016:
Portraits of 13 characters. (width=32)
Right-Up/Right-Down arrows and 4 other symbols. (width=48)

F<00>018:
"Wrong disk!!" image. (width=194)

F<00>20:
"Level up!" image. (width=112)

Thank you Zande, and my appologies... I said in my first post that I read some posts by Cyberman and Zidane, but it was Zande. Sorry. I could just as well have said Zorro.

I have some idea as to what is inside each directory, but not all the entries. Your list is more complete than mine. This is the first psx game I look into so I'm not too familiar with the structures. After stripping off the TIMs I jumped directly to the weapon models that I thought would be simple and then to the directories.

Entry 0012, as you say is the World Map geometry. It's a little strange as there is some redundancy and missing parts. I'll post more information when I get home.

----------------- I'm home

Zande, what I didn't mention earlier is that I am interested in any information I can get. I don't mind no mess as it can't be worst than mine.

I don't remember seeing that model before, but it looks great. With bones and all. (Mine are all "contractured". No bones.) I think I'll skip the models then. Did you get to add the textures?


This is what I have at the moment about the World Map. Its geometry is defined in DIR12. There are 2 files and each one of them has more or less the same information. I'll describe the first one, as the second one seems to be transposed. Both of them are divided into sectors (0x800 bytes).

The World is defined as a grid of 24 columns and 20 rows in the first file. (The number of rows may differ a little because of rows full of water. Should check the second file.) Each cell of the grid points to a block and each block is divided into 4 meshes (2 meshes * 2 meshes).

The general structure is:
- Grid definition.
- Definition of blocks and texture groups.

The first two sectors have the grid definition. They don't define the dimensions for the grid and the data for the first cell can be found at offset 0. At the moment, I'm not sure if each cell is defined by 4 or 8 bytes. To render a correct version of the map I assumed they are 8 bytes long:
(4 bytes) Reference to block, version 1.

(4 bytes) Reference to block, version 2.

Each version may represent the state of a cell at a given moment: open cave/closed cave, standing construction/destroyed construction, etc. (Or perhaps  some animation.) The few I checked had the open/closed cave.

The way I rendered a version of the World Map that makes sense is by rendering all the version 2 blocks. If version 1 blocks are used instead, the World is almost empty.

Each reference to a block is:
(2 bytes) Pointer to block. (Number of sector where block definition starts.)
(1 byte)  Attribute1.
(1 byte)  Attribute2.

The blocks are ordered in the file starting with Chokobo's Paradise in the top-left corner, then the rest of the cells of the first row, second row, etc.; and so are the cells of the grid.

Note: A cell of the grid may have more than one block associated, but only one is shown at a given time when rendering the World.

If Attribute1==0, then the cell is water without consideration for the block pointed to. If Attribute1!=0, then the pointer to the block is used. I haven't figured out any other meaning for Attribute1 nor Attribute2.

After the grid definition, come the blocks and some TIM textures in between a variable number of blocks. As an example:

Block-Block-Textures-Block-Block-Block-Block-Textures-Block-...


Each block has exactly 4 meshes arranged like this:


The definition for a block is (all pointers in bytes, not sectors, relative to offset 0 of block):


Each mesh has a rectangular proyection on the base, but they aren't limited to concave/convex surfaces.
I haven't figured out the association between triangles and textures yet. I should install epsxe to watch the vram.


Texture groups have this structure:
(4 bytes) Number of textures.
(4 bytes) Pointer to first texture.
... Ponters to more textures.
First texture. (TIM)
... More textures. (TIM)


I estimate the in-game field of vision should be of 5*5 square blocks, with the protagonist in the center. Perhaps a little wider in higher places. That's the approximate distance where the fog makes it impossible to see the mountains.

I'm having problems with the rendering of locations like cities, etc. as there is a hole instead. Perhaps the model for the cities is somewhere else or I'm making some mistake.

I also found some kind of correlation I still haven't figured out: The texture groups seem to be near the cities or places of interest.

I hope you don't mind there is some especulation in what I describe. I'll try to get one of those services to upload some images soon.

I found triangles and quadrangles in the models for weapons and enemies, but  I don't understand when you say there are 3 different types. Do you mean they are arranged in different ways or are you refering to some other attribute?

Anyway, what you said about quadrangles made me look a little better into the World Map and I had a bug in the code that made holes appear where cities should be. I was taking the number of triangles as a 1 byte value instead of 2 bytes as documented above. I was missing 256 triangles in complex meshes.

I think I also found the relation between the textures and the cities, but that's for another moment.

These are more likely to be script information than just dialog

This means they likely have window and various other symbol information embeded into them.  Fortunately I've no problem reading the dialog (because of my cute app).

I'll have to explore the DB XX XX etc thing more.
I think you should think of most data as 32 bit aligned also. In any case I'll see what I can find out based on that. Sheesh you folks are already twiddling with complete 3d data (sigh). I'm getting old

Cyb

Well, it must be that I have the wrong definition of TIM. As I said this is the first time I look into a psx game. The idea I got from reading some documents in the Web is that they have a header starting with 0x00000010, followed by the color format (2, 3, 8 or 9), ..., cluts, ..., color information (RGB or index to clut depending on color format). The first routines I made read this data and converted them to BMP. Am I wrong up to this point?

Then I wrote some other routines to convert the bytes in a generic file to grayscale pixels, allowing to resize in the X dimension. With this I found some other images I wasn't able to find with the first routines; I looked in an hex editor and they didn't have the header described above, so I called them non-TIM. Perhaps they are TIMs without a header?

If that's the case, I'm sorry I didn't research more. Can you recomend a doc?

The first image I found with the header is the one with the letters, numbers, kanji, etc. The first images I found without the header were the ones I described in a previous post.


About the 32-bit alignment, I know what you mean, and I think you don't understand the meaning of the byte/unknown thing because I never told you about it.

I know the psx is a 32-bit machine so the first thing I would do is try to align the data to 32-bit boundaries. I'm not trying to do a byte by byte description of the structures.

The "0x04 ZZ ZZ ZZ" is not 0x00000004 as I described it above. It is in *most* blocks of the World Map, but not in some of them; especially the ones that are immediately before a image group. (Bytes at offset 1 and 2 seem to have independant meaning.)
What I'm sure about is that byte 0x04 is allways present at offset 0, that offset 1 and 2 are mostly 0, that they don't seem to depend one on the other, and that I don't know what they mean.

Another example is the "number of vertices/number of triangles" word. I'm almost sure you'd be tempted to take the byte I marked as unknown and make half a word with the "number of vertices". I did that at first, but when I kept on looking, I found some blocks that where generating vertices' coordinates with information that was clearly triangle data.
The bug I had with the triangles was because I didn't look at the messy docs I had when programming that bit. I did it on memory and thought the triangles where 1 byte also. (I even padded to the next word.)

The 20 bytes I marked as unknown, I did because of lazyness and because I didn't see a clear separation between them. The next 4 bytes I marked as unknown, I did because they were clearly appart from the previous 20 bytes.

Sorry again I didn't explain everything, but althogh I'm a newbie in the psx "deconstruction", I'm from the zxSpectrum "deconstruction" ages and I've been doing it for 13 years in the PC and some other minor platforms.
(Yes, I know it's not right to talk about oneself, especially without proof, but at least that could give you an idea of what to expect.)

I'll try to add all the information and little quirks I find in the structures, but as I said, I'm a little messy with the docs and I take some things for granted.

Some of the quirks I didn't mention are:
- The easy way to find the end of the last file in a directory. (But I'd say you already figured that out.)
- That there is a block in the World Map that is all 0x0. It doesn't even have the 0x04 at offset 0. (I simply skip it.)
- That you can have image groups with 4 images, so you'll have to watch out not to interpret them as block definitions.


About the World Map, I didn't have much time these days and I haven't even made the first texture appear on the screen, but I did some "hand-mapping" (don't even expect 1FPS.) Image groups seem to be loaded into memory in a rectangle of 128*256 pixels where the images in the group are arranged. They seem to be loaded dynamically when rendering a city.
I think I'll shut up about the World Map until I'm able to show a textured city.

Thank you Cyberman. I'll take a look at the MIM format.




I'll try to classify all the images I found and associate them to files and directories. It will take me some time, but if you are interested in the ones I described as non-TIM, you can take a look at DIR00. I described all the images I found in that directory. You can find that info in the eighth post of this thread, but I'll make a little recount: (I used your filename nomenclature and all widths are in pixels.)

They seem to be all images that appear in the menus/mini-games options and they are logically grouped in each file, so I assume they give information on what to expect to find in each file.



I meant, the little images that tell you where to find goodies in the world with the chocobos. I said "low contrast" because I was looking to them in grayscale and they have a palette with few colors, so in grayscale they look almost black. (I added an inverse look up "feature" to the application as it's easier to see them with a white background.) I remember I added the corresponding palettes some time ago and the colors where right.
Just look into file 007 of DIR00.


In file 008 you can find some symbols and backgrounds used in the card game, so I'd expect the rest of the file has instructions or something related to the card game.




This file has only 1 image (that I was able to find) with the background where characters are displayed when you read a letter you got from someone, the ticket Vivi has when you start the game, and any other key item. (Maybe the name in English isn't "key item"?)



When I say portraits, I mean the head/face of the characters that apper in the menus. (By character in this context I mean Zidane, Vivi, etc., not letters and numbers.)
If you notice, when you are about to save and you access a memory card there is a book that passes some pages as if you were reading them. That's what I meant about the animation.
As the file seems to be related to file loading/saving, I'd say that the portraits are of the characters you have the possibility to save games with.
I don't remember if the number is limited to 10 characters when saving.




I only found images for characters' heads/faces so I don't know what they are for, but I'm pretty sure they are part of the menus as they look exactly like the 10 above.



The portraits are the same as above, and I didn't recognize the arrows at first, but all are symbols shown when you buy/sell stuff. The arrows tell if a particular character would be at an advantage/disadvantage if it equips a given armor/weapon/item.
So, file 016 must be related to the buy/sell stuff.



This one has an image that tells you to put the right disk in the drive. So it must be related to disk management.



This one is the little text that appears over the characters that leveled up after a battle.


If you found any of those images in DIR00 (or much less likely in other directory) I'd say it's a mistake I made because I didn't know the TIM format as I should.


About the cards' monsters, world textures, weapon textures, enemies textures, field backgound/character textures, palettes and some other I have them as TIM with the header, just as you mention. I'll document it.
I have as non-TIM the images of the last directory, where Zande said there was summon data and I mentioned there where little stars and thunder (lightning really - I messed up there. Although there are AKAO bits there.)




Well, I didn't say anything because I took it for granted, so that's my fault. I don't usually explain every bit of info I don't know unless I have a feeling of what it is and that's not the case with the fields in the structure above.

I'd say the more we give the better for everyone. The reason I started working on ff9.img is because I couldn't find tools to look at the models, scenery, etc. There was little info, also. Not that I would do anything with the data, just to look what's in there. I'll probably drop it as soon as I lose interest, but at least I think there is some movement forward.

Anyway, I'd like to ask if you have any objective for this data. Not that I mind, just curious.

Some other thing I forgot to mention is that the padding for the u,v texture coordinates isn't always 0x0000. I won't know what they mean until I have some textures in the world.




That's possible. I think the world in the second file is transposed to the first file (but maybe it's rotated 90 degrees.) That would make it unnecesarilly complicated to associate data from one file to the other. But who knows, it seems to be an optimization as you say.
It's been a long time since I played the game and I lost all the savegames so I don't remember quite well but wasn't there a strange movement when you entered the airship? (I'm slowly starting to play again.)

That would be great if you entered information in the wiki as I looked there a few weeks ago and didn't find anything on ff9.




I remember those images. There are some that include a small Zidane skin (for the World Map), along with chocobo's and moogle's (the one that lets you save the game.) The little airships are the ones you see when you exit the ice cave, near Dali. (I just got there.)

About the textures, I think the World Map files only include textures for the buildings and some details, but I found lots of terrain/building TIMs into file 021 of DIR01 or somewhere near. I don't know if they are used for the World Map, for the battles, or maybe both, but that would explain the lack of textures in the World Map files. (Most common textures accessible to the World, not so common textures accessible to the continents and less common defined near cities, etc.)
I even saw scaled textures so the World rendering is surelly optimized to account for the distance to the camera, but then, this is pretty common.

And I said I wasn't going to mention the WM.

I'm going to brush off my theory hat. This has helped with poor souls stuck in the past.

The program flow for any Final fantasy game up to and including 9 uses the same module system. These all use the same codebase, or design pholosophy with some tweaks. 10 had a massive rewrite of the field module, a new "cinamatic" module added, and the worldmap was reduced, and battle was coupled more tightly to the modules.

Anyway.

Blindly guessing, not having a FF9 disk in front to me, you have to therorize that FF9 executes much like it's Final Fantasy brothers and sisters of the past. Start at the top level and work your way down.

We know that Square like st seperate it's system and give each section to deveopment teams. So you break out battle, menu, field, minigame, and worldmap.

Careful with minigame though, a lot of minigames are written in field script, which are a part of field. In FF7. the CPR game, Chocobo breeding game, and some puzzles are examples of this. (Also of note, the "wandering in the snowstorm/plant posts to keep yourself stright" game is actually a worldmap minigame...)

The icons save to the memory card are "almost tims" and very tiny. They are in the menu system.

Keep in mind. The Menu module is probably the most core system to the game, second to the kernel and above field. It's the global variable manager, and is responsable for save/loading of data. It itself is broken into sub modules that are staticly pasted into memory. (This has been the same Modulus Operondi for 7 and 6)

Fieldscript, save for it's 3d functions, is the same as FF6, and was only slightly tweaked for FF8. The commands, from what very liittle poking I have found, are the same for FF8, PE, and most likely FF9 as well. (Is there a debug room for 9, or did square finally remove that from production releases?) 8 and 7's "Startmap" ,the inital debug room, is set up exactly the same (0,0,0 camera and 0,0,0 character position)

The upshot....

Somewhere in that blob of data is a "kernel.bin" that has inital savemap info plus a "start game" overwrite. (The inital savemap should drop you into the debug room, while the overwrite starts the inital fieldscript for the game)

Look for zgip headers, they start with 0x1F8B080000000000, actually, the "magic number" is 0x1F8B, but exsize that out if you see it, uncompress it, and se what's inside.

Many times the polygon headers are actually GPU command headers, cross refrence with my PSX tech docm looking in the GPU section. In FF8 the ploygons were defined by "blank" gpu commands. (Missing rotation data, which would be supplied by the GTE during the creation of the OT for DME to the GPU)

Oops, Let me retranslate that....

When a PSX renders 3d stuff to the screen it has to go though the GPU. This can be done by directly sending a packet via hardware registers, which is slow, or though Direct Memory Access ->(DME). If you do a DME transfer, a real keen way is to line your GPU packets up in a linked list, sorted by depth. These sorted linked lists are called "ordering tables" ->(OT) and are sorted by an algo by depth on the Z access. An efficent way to get a model into the GPU as fast as possable is to have a model pre-made of GPU packets in a psudo-linked list with the GTE rotation data missing. During the GPU "kick" each packet has it's GTE data put in, sorted by Z depth, and then the whole Linked list is fired off to the GPU for rendering via DME.

(wow, it almost seems like I know what I'm talking about)

So here's some tips.

1. Look for PsyQ headers (TIM, SEQ, VAG)

2. Look for gzip headers

3. Look for GPU packets.

4. The system was broken to descrete parts during deveopment, they are "self contained" for the most part. You will rarely see data of one module bleeding into another. Find the boundries. Think in terms of what programmer was responsable for what part. Assume the only talked to each other at tame-wasting meetings every so often, and only to give update on how thier module is going.

I don't think I answered your questions. But That ws really fun to write.

There has been a long calm. 
In any case I've been quietly (noisely is not possible) working on a better UI and processing the data files.
However I've discovered a few things about DIR00 and it's associated files
F<00>000 contains only 1 DWORD in little endian format (00000015) or 21 in decimal First word..
The first DWORD I believe identifies the file (hmm).
F<00>001 begins with 00000005
F<00>002 begins with 00000006 and is followed by 'Disc Cover Open\0'
F<00>003 begins with 00000007 it also has a number of printf format strings in it such as
"Illigal Animation Data" <--- actual data hehehe
"w_movementChange : %d -> %d\xA\0"
"MAP JUMP\xA\0"
"w_frameMapDestructor:\xA\0"
"w_frameSystemDestructor:\xA\0"
"*[ Request from script:Weather:%d ]\xA\0"
"*[ Request from script:Navi Active:%d]\xA\0"
etc.
F<00>004 begins with 00000008 it has a number of words that run together
It contains a load table of locations within the PS1 memory and a series of phrases
"ENEMY CARD SELECT\xA\0"
My guess is this is the card game
F<00>005 begins with 00000009 it also has a long load table of PS1 memory locations.
F<00>006 begins with 0000000A has a short load table and has a few printf format strings in it
"%2d Bankroll\0"
"%ld Wager\0"
"Stand\0"
"Hit\0"
"Double\0"
"Split\0"
F<00>007 begins with 0000000E
F<00>008 begins with 0000000F
F<00>009 begins with 00000011
F<00>010 begins with 00000010
F<00>011 begins with 00000012
F<00>012 begins with 00000013
F<00>013 begins with 00000014
It has words such as
"File00\0"
"/DISC\0"
in the begining
F<00>014 begins with 00000015
has a PS1 memory load table at the begining
(5) locations
F<00>015 begins with 00000016
F<00>016 begins with 00000017
F<00>017 begins with 0000000F
that's all that is contained in it
F<00>018 begins with 0000000D
and looks to have a TIM file in it.

I'm getting false positives reguarding the DB files (mutter) so I may need to work on that a bit more
Current screen caps.
Directory Information (woo?) including those pesky 0xDB encoded files
http://www.geocities.com/cyberman_phillips/Images/DIR04_1.JPG
Hex Dump of first data section of first file on screen.
http://www.geocities.com/cyberman_phillips/Images/DIR04_2.JPG
Note: These are linked because the system killed the images so there was no point in putting them in with \[IMG\] \[\IMG] usage. All Images appear to be restricted to 640 pixels across.

Cyb

1) JPEG files are unlikely to be in a PS1 game.

2) my computer crashed so I'm waiting to restore my files (sigh).  To be precise the Hard Disk expired mostly.

3) I'm trying to not scream a lot. From frustration with crashing software.  I think my MB is partly to blame.  Life goes on!

4) DIR02 is likely script data.  This means FF9's engines is a bit different in how it organizes it's data compared to FF7.

Since FF9 is a linear progression game it means that it's likely the script and text for each part of the game progression is located in DIR02 in the order they appear.  That also means that you should find the tutorial things that appear during the game in there as well.
If you find there is more data than text then it's script if not the script is hidden elsewhere.  It would be good if you could discover this though

I suppose I need to restore my code ASAP

Hopefully I can cool my dead HD brain a bit to do so

Cyb